Should this have "error" as an option to follow the pattern of Flow Delete Requests? I think the intention of that pattern is that the error object is only present when status is set to error. If we want to follow that pattern, and we want to make this user setable, we might want to think about the best way to indicate the values a client may set and the values a service instance may set. We should also probably describe what a client should do if a webhook enters the error status. e.g. could they set it back to enabled to try again if they fix an issue on the receiving end? Would there be any benefit to having the separate created and started states of the Flow Delete Requests here too? Or is it fair to assume the startup time is negligible?

I did not think about it to this depth, apologies. You have valid points, my response is "yes"! The difference between created and started might be a way of indicating that at least one POST has occurred since creation? Just thinking out loud. I am certainly not too opinionated on the enum values. I just thought creating this PR was better than just leaving you to iron out the details ;)